docs: clone to a short path on Windows to avoid MAX_PATH build failures (#678)#684
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR addresses ARM64 Windows dev-box build failures for the tests/perf_bench/** WinUI benchmark apps by conditionally skipping their builds when the host OS architecture is ARM64, while keeping x64/CI behavior unchanged.
Changes:
- Added a
tests/perf_bench/Directory.Build.targetsthat re-imports the repo-root targets (preserving root AOT/trim settings) and computes a host-arch gate (PerfBenchHostArchitecture+PerfBenchSkipWinUiAppOnArm64). - Added a conditionally imported targets file that replaces the WinUI app
Buildtarget with a no-op (emitting a high-importance message), so leaf perf_bench WinUI executables are skipped on ARM64 hosts whilePerfBench.Sharedstill builds.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tests/perf_bench/Directory.Build.targets | Re-imports root targets and defines an ARM64-host gating property; conditionally imports the skip targets only for WinUI WinExe projects. |
| tests/perf_bench/build/SkipWinUiAppBuild.Arm64.targets | Provides a no-op Build target (with an explanatory message) for gated WinUI app projects on ARM64 hosts. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
azchohfi
changed the title
azchohfi
pushed a commit
that referenced
this pull request
Jun 26, 2026
Address Copilot review on #684: - Make the src\ exclusion case-insensitive (OrdinalIgnoreCase) so a drive-letter casing mismatch between MSBuildThisFileDirectory and MSBuildProjectFullPath can never cause the shipping library under src\ to be redirected. - Quote the StableStringHash() path argument so a project directory containing parentheses or commas (e.g. 'Program Files (x86)') cannot break MSBuild's property-function parser. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
azchohfi
pushed a commit
that referenced
this pull request
Jun 26, 2026
Address Copilot review on #684: explain that 145 is an empirically chosen cutoff (MAX_PATH 260 minus the ~100-115 char obj/bin output subtree the SDK/WinUI toolchain appends below the project dir), so future edits don't accidentally invalidate the gate. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
azchohfi
pushed a commit
that referenced
this pull request
Jun 26, 2026
Address Copilot review on #684: the gate keyed only off OSArchitecture, so it could activate on non-Windows Arm64 hosts (macOS/Linux) where LOCALAPPDATA is unset, yielding a malformed BaseOutputPath. The failing tools (XamlCompiler/MakePri) are Windows-only, so require OS == Windows_NT and a non-empty LOCALAPPDATA. Inert on non-Windows by construction. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Long checkout paths (e.g. deeply nested or OneDrive-synced folders) push a project's generated obj/bin output past the Windows 260-char MAX_PATH limit, which the Windows App SDK's 32-bit XAML/resource compilers cannot handle (MSB3073 / PRI210 / APPX0002) -- most visibly on ARM64 dev boxes where those tools run under emulation. Document the short-path recommendation in README Quick start and CONTRIBUTING Prerequisites. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
azchohfi
force-pushed
the
azchohfi-fix-perf-bench-arm64-xaml-build
branch
from
d2f67c3 to
8752c91
Compare
azchohfi
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Documents that the repo should be cloned to a short path on Windows to avoid
MAX_PATHbuild failures. Docs-only — no build-configuration or source changes (README.md + CONTRIBUTING.md, +22 lines).Background (issue #678)
On Windows, the Windows App SDK's XAML markup compiler (
XamlCompiler.exe) and resource indexer (MakePri.exe) are 32-bit tools with no long-path support. When the repository is cloned to a long path (a deeply nested or OneDrive-synced folder), a project's generatedobj/binoutput paths can exceed the Windows 260-characterMAX_PATHlimit and the build fails — e.g.MSB3073(XAML markup compile) orPRI210/APPX0002(resource indexer). This is most visible on ARM64 dev boxes, where those tools run under x86 emulation, and it reproduces on a pristinemaincheckout (pre-existing; not a regression). It does not affect x64 CI or the/perfgate, which build from short paths.What changed
git clonestep.core.longpathsclarification (it lets Git check out long paths, but the WinUI App SDK build tools still require the short checkout path).Why docs instead of a build-config change
An earlier revision of this PR redirected each project's
obj/binto a short%LOCALAPPDATA%path on ARM64 hosts. Per maintainer preference that approach was dropped in favor of this documentation note: the failure is a dev-box ergonomics issue (clone location) rather than a product/CI defect, and cloning to a short path avoids it entirely without adding build machinery.Validation
Docs-only; no build impact. The guidance is verified empirically — relocating an affected checkout to a short root (e.g.
C:\src\) makes the same toolchain build successfully on this ARM64 box.Closes #678.